\chapter{Implementation}
This chapter opens the implementation part of this thesis. The goal of this thesis is to design a software that will experimentally test proposed solutions of the tasks described in the theoretical section with the documents received from CEZ, a.s. company. In the beginning of this chapter we will discuss requirements on the software, then we will focus on architecture and its composition. The following chapters of the implementation part describe each module in greater detail and enlist problems that we have encountered.

\section{Requirements}
The software has to be able to extract informations from documents of various types (Microsoft Word, Excel, Power-point, PDF). This task includes extraction of plain text from these documents, invoke linguistic processing, process the linguistic results, create and apply search rules on them. The extracted knowledge has to be converted into graph representation and stored in the Virtuoso database. Part of the application is GUI that will allow a user to interact with the rest of the application. These are the general requirements for the application based on the goals of this thesis. To summarize the requirements:

\begin{itemize}
	\item Extract plain text from documents
	\item Process extracted text with the linguistic tool \emph{Treex}
	\item Process the \emph{Treex} results
	\item Provide an environment to create search rules for IE
	\item Apply and extract informations
	\item Create a graph representation of the IE results
	\item Store the information in Virtuoso database
	\item Provide user interface to search and retrieve data from Virtuoso
	\item Gather statistical informations about the informations extracted from the documents
\end{itemize}

Although this is an experimental application, we should consider also future usability and extensibility of this application that will lead someday into a real-life implementation. That implies use of a central database storage and a machine that will provide enough computational power for linguistic processing tool \emph{Treex}. These requirements are met in a client-server model, thin-client implementation. Application therefore will be deployed on the server as a web application, database and \emph{Treex} however do not need be deployed on the same server, to reduce a server workload we have to design the application that will allow to have them on a remote machine. Clients will work with the application trough web browser. Application will be developed in \emph{Java} programming language and will be using \emph{Spring framework}.

\section{Architecture}
We have described software requirements in the previous section and proposed a model of our solution. We have to find a suitable architecture for our application. The task can be decomposed into smaller ones, allowing us to create modules that will implement individual requirements. However the requirement can change in time, so we need to design these modules in a way that will minimize impact on implementation of other modules. Since user will interact with the application trough a web browser using thin client approach the MVC (Model-View-Controller\cite{MVC}) design pattern will be the most appropriate. \emph{Controller} will react on user events from the \emph{View} component and will send requests to the \emph{Model}. Once he will get the notifications (results) from the \emph{Model} it will update the \emph{View}. See figure \ref{fig:MVC}.

\begin{figure}[ht]
\centering
\includegraphics[width=0.7\textwidth]{./img/mvc.png}
\caption{MVC design pattern}
\label{fig:MVC}
\end{figure}

If we consider the requirements and the definition of the MVC pattern, we have to divide modules into \emph{Model}, \emph{Controller} and \emph{View} components. \emph{Model} contains domain logic and therefore all modules that will be serving this purpose will be added there. View will be a web browser UI, Controller can be any class that will interconnect all modules. The modules have to implement specific interfaces to provide uniform access from \emph{Controller}. The MVC pattern does not describes the interaction between domain and data layer and therefore we will implement our own solution.

\section{Architecture in details}
The application architecture is shown on the figure\ref{fig:Architecture}. \emph{View} and \emph{Controller} will be implemented in a same model, they do not need to be in a separated module explicitly. There will be 5 modules in the \emph{Model} component. \emph{Treex} and Virtuoso database can be deployed on different server and we mark them in the architecture as remote entities.

\begin{figure}[ht]
\centering
\includegraphics[width=0.5\textwidth]{./img/architecture.png}
\caption{Software architecture}
\label{fig:Architecture}
\end{figure}

\subsection{Model}
Each of the module implement part of the requirements and represent the application's domain logic. To provide extensibility, each of the modules will be implementing interfaces. Any future module that will implement any of the interface can replace the module. it will minimize the chance of affecting implementation of other modules. Modules that are part of the \emph{Model} component:

\begin{itemize}
	\item \emph{Text Extraction} - Will receive any of the document provided from CEZ a.s., will extract a plain text from it, will store it in a file and will return reference to that file. The supported document types will be Microsoft Word, PowerPoint, PDF. During the extraction process the structure of the text must be intact. To reach this goal some post processing will be needed.
	\item \emph{Linguistic processing} - Will receive a plain text file and will invoke a linguistic text processing. In this case it will invoke \emph{Treex}. However this module could be switched by any of linguistic processing tools, for example \emph{Stanford CoreNLP} and others. To support extensibility and load balancing, it will invoke the linguistic processing remotely. To support this feature, we have to invoke this service using Spring RMI.
	\item \emph{Process linguistic result} - Treex writes results in \emph{CoNNL}\cite{Conll} format. The modules will get a file containing the results of linguistic processing in this format. It will parse the result and will create an internal representation of the document, that will contain all linguistic informations about the document such as dependency trees of the sentences and for each word its morphological tags, lemma, original text etc. It will return object that will contain the internal document representation to allow IE based on specific patterns.
	\item \emph{IE} - This module will receive internal document representation that will be created in the previous module and search configuration file. Search configuration file will contain information about the search patterns. The module will process the document based on the search configuration and will extract triples and terminology expressions with their frequencies. The module will return an object that will contain set of extracted triples and set of terminologies.
	\item \emph{DB access} - This module will provide access to the virtuoso database, or any other semantic database that will implement specific interface. This module will create a graph from information extracted from a document and store them in the database. On top of that, the module will enable to search for a document based on parts or full triples and terminologies. Besides document search, it will allow to search for triples and terminologies. It will return any information that is stored in the database based on the type of a request. The module will use Virtuoso JDBC driver to connect remotely to the Virtuoso database.
\end{itemize}

\subsection{View and Controller}
View component will allow user to interact with the application. The application needs to be accessible via Web browser, since domain logic will be written in \emph{Java}, use of \emph{Servlet} is almost obligation. To simplify interaction between the UI and the rest of the application we should look for a Java framework that will allow us to create UI and easily embedded it into our application. One solution might be a \href{http://www.gwtproject.org}{GWT} (Google Web Toolkit) which is development toolkit for building and optimizing complex browser-based applications. Another solution is \href{https://vaadin.com/home}{Vaadin} that is ava framework for building modern web applications. Both options are suitable, however \emph{Vaadin} is relatively new, it focuses mainly on server-side architecture and uses GWT for rendering the resulting web page and it would be nice to learn something new. As mentioned earlier Controller can be any class that will interconnect modules, processes user requests and pass them to the domain logic. In the opposite direction it will receive updates from the domain logic and will fill the UI with a new data.